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Abstract - This paper provides a credible approach for 
implementation of ISHM capability in any system . The 
requirements and processes to implement ISHM capability are 
unique in that a credible capability is initially implemented at a 
low level, and it evolves to achieve higher levels by incremental 
augmentation. In contrast, typical capabilities, such as thrust of an 
engine, are implemented once at full Functional Capability Level 
(FCL), which is not designed to change during the life of the 
product. The approach will describe core ingredients (e.g. 
technologies, architectures, etc.) and when and how ISHM 
capabilities may be implemented. A specific 
architecture/taxonomy/ontology will be described, as well as a 
prototype software environment that supports development of 
ISHM capability. This paper will address implementation of 
system-wide ISHM as a core capability, and ISHM for specific 
subsystems as expansions and evolution, but always focusing on 
achieving an integrated capability. 

I. INTRODUCTION 

The term Integrated System Health Management (ISHM) 
is used to describe a capability that focuses on determining 
the condition (health) of every element in a complex System 
(detect anomalies, diagnose causes, prognosis of future 
anomalies), and provide data, information, and knowledge 
(DIaK) - not just data - to control systems for safe and 
effective operation. In the case of NASA, this capability is 
currently done by large teams of people, primarily from 
ground, but needs to be embedded on-board systems to a 
higher degree to enable NASA's new Exploration Mission 
(long term travel and stay in space), while increasing safety 
and decreasing life cycle costs of spacecraft (vehicles; 
platforms; bases or outposts; and ground test, launch, and 
processing operations). 

ISHM functional capability level (FCL) indicates how 
well a system can perform the following suite of functions: 

List of functions: 

• Evaluate condition of system elements. 

• Detect anomalies and their causes. 

• Identify overall system state. 

• Predict system impacts. 

• Recommend responses to mitigate anomaly and 
failure effects. 

• Communicate contextual and timely DIaK and 
situational awareness to system elements and system 
operators. 

Implementation of ISHM capability is not a once-and- 
done task. It has to be systematic and evolutionary. 


Affordable and sustainable systems must, by definition, have 
embedded ISHM capability. The following sections describe 
an approach defined by three activities that form the basis for 
implementation of a credible on-board ISHM capability. 
These activities are: Definition of the core elements, 
systematic implementation approach, and the role of 
supporting infrastructure such as testbeds. 

II. CORE ELEMENTS FOR ISHM IMPLEMENTATION 

ISHM capability is primarily a data, information, and 
knowledge (DIaK) management problem, integrated 
throughout a system. Attempts to implement ISHM in the 
past have primarily focused on data, and have not emphasized 
integration across all elements that make up a system. The 
following capability must be met: 

Capability list: 

• Distributed storage. 

• Distributed processing. 

• Distributed intelligence. 

• Availability of DIaK to any element as needed. 

• Simultaneous execution of multiple processes 
representing models that contribute to the 
determination of the condition of each element in 
the system. 

Figure 1. Distributed Hierarchical Architecture with Intelligent 
Elements 

A. Architecture, taxonomy, and ontology (ATO) for DIaK 
management. 

In order to implement credible ISHM capability, ATO to 
meet the capabilities cited in the list above must be defined. 
Typically, architectures have been centralized and focused on 
data. Hence, data from all sensors is individually wired to a 
central signal processing unit, for use in control and 
monitoring activities. This approach has worked well, but 
ISHM for higher complexity systems, can be more efficiently 
developed using distributed and/or hierarchical architectures. 
The need and urgency to define a common architecture for 
ISHM is evident from efforts supported by the industrial 
community and the Department of Defense. These entities 
have engaged in defining an architecture (as well as standards 
and an ontology) for condition-based maintenance, 
denominated Open Systems Architecture for Condition- 
Based Maintenance or OSU-CBM [1] (Figure 1). Such 
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architecture is distributed, but not hierarchical, or at least, 
hierarchy is not mandated by the architecture. This approach 
is advantageous in that any element is linked to another 
element directly over the same bus, but it can result in 
inefficiencies as a consequence of higher processing 
requirements for each element and very high bus traffic. 
Another suitable architecture for ISHM is shown in Figure 2 
[2]. This distributed-hierarchical architecture (DHA) can be 
used to represent any complex system, and includes the 
necessary paths and elements to meet the requirements in the 
list above. Intelligent Sensors and Components [2,3] share a 
bus that provides connectivity among them, as well as with 
processes and controllers. The architecture is “Process- 
Centered,” since process models are central to the 
performance of ISHM related tasks as described in the list 
under the Introduction Section. The definition of process is 
generic as it may represent an analytical equation, a logic 
rule, a Fuzzy Logic representation of a process, statistical 
relationships, etc. 


unit, using virtual elements such as virtual intelligent sensors, 
virtual intelligent components, etc. In this manner, one may 
apply the DHA to legacy systems without physically 
changing any of its elements. 
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Figure 2. Distributed Hierarchical Architecture with Intelligent 
Elements 


The DHA is also defined in terms of “Intelligent 
Elements.” This is necessary, because the underlying 
inspiration for the system is that each element be capable of 
determining its health, using local DIaK as much as possible, 


A taxonomy based on the DHA should make possible the 
List of Capabilities in Section II in a way that supports 
incremental capability augmentation and incremental 
expansion. An object-oriented taxonomy is well suited, since 
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Presentation layer is the man / machine Interface. 
May query all other layers. 

Decision support utilizes: spares, logistics, 
manning, Etc. to assemble maintenance options. 

Prognostics considers health assessment. 
Employment schedule and model reasoners that 
are able to predict future health with certainty level 
and error bounds. 

Health Assessment is the lowest level of goal 
directed behavior. Uses historical and CM values 
to determine current health. Multi-site Condition 
monitor inputs 

Condition Monitoring gathers SP data and 
compares to specific predefined features. Highest 
physical site specific application 

Signal Processing provides low-level computation 
on sensor data 

Data Acquisition- conversion/ formatting of 
analog output from transducer to digital word. 

May incorporate meta-data. Ala. 1451.X 

Transducer converts some stimuli to electrical 
signal for entry into system 


Figure 1. Open Systems Architecture Enables Health Management for Next Generation 
System Monitoring and Maintenance Development Program [1]. 


but accessing global DIaK when needed. 

Although the elements in the DHA appear to be physical 
units, they may be implemented as virtual entities. In fact, the 
entire DHA may be implemented in one central processing 


the elements in the architecture can be defined as object 
entities with embedded local assets and communication 
attributes to determine their own health. Along with object 
orientation, a suitable software environment is needed with 
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tools to manage DIaK. These tools should include those 
normally available in artificial intelligence applications 
(inference engine, structures for management of symbolic and 
qualitative information), as well as tools for 

analytical/engineering applications. 

Ontology also needs to be defined, since a specific 
language is needed to ensure effective and accurate 
communication. Ontologies are implemented by standards 
and protocols. An example is the TEDS or Transducer 
Electronic Data Sheet standard (IEEE 1451.x). This standard 
defines a common set of specification-related words and the 
means to organize, store, and share information normally 
available in specification sheets and/or manuals. 

B. Standards 

Standards to manage DIaK are currently being developed 
by IEEE and others [1-4]. These standards need to be 
augmented to include health information, and also to cover 
other elements, such as components (valves, etc.), actuators, 
controllers, and processes. 

The area of smart sensor development is active, with one 
important focus being the definition of sensor interfaces to 
allow “plug and play.” IEEE has developed an extensive set 
of standards for “smart sensors” including IEEE 1451.0-.5 
[3]; IEEE 1451.6 is in development. The nature of these 
standards has been widely published [5]. For our purposes, 
the presence of an embedded processor in a sensor 
application does not automatically satisfy the definition of 
“smart” unless it includes some level of compliance with the 
IEEE 1451.X family. For example, [6] describes a “smart” 
sensor, but the application lacks conformance to the IEEE 
1451 standards. In comparison, [7] describes a smart sensor 
that does conform to IEEE 1451. We suggest reserving the 
use of “smart” for the latter applications. 

We have adopted a generalized model of the IEEE 1451 
smart sensor that consists of the transducer (XDCR) hosted 
by a transducer interface module (TIM), which provides 
signal conditioning and data acquisition along with being the 
repository of a collection of “electronic data sheets” including 
transducer (TEDS), health (HEDS), and component (CEDS). 
The TIM communicates over a transducer independent 
interface (Til) with a network capable application processor 
(NCAP). The NCAP in turn provides network interface to the 
wider application system. Figure 3 shows the block diagram 
of a representative smart sensor. 

III. SYSTEMATIC IMPLEMENTATION 

Implementation of ISHM capability must follow a process, 
which also requires a change in mindset with respect to the 
classic engineering design process. 


A. Engineering design process 

Insertion of ISHM capability must be considered 
throughout the design process, from concept to product, to 
operations, to maintenance, and to decomission. Just like 
prior evolutionary changes in the design process, e.g. “Design 
for Manufacturing,” or “Design for Manuracturability,” or 
even “Design of Mechatronic Systems;” there is a need for 
“Design for ISHM.” 



Figure 3. Block diagram of an IEEE-1451. X smart sensor showing 
the transducer element (XDCR) supported by the TIM, which is in turn 
interfaced to the NCAP via the Til. The TIM also stores various 
electronic data sheets. 

Any product design process should be ISHM-Minded, 
hence, for every element of a system, one should ask the 
following questions: 

• What is the set of information that may be useful 
to help determine the condition of the element? 
For example, potential failure modes. 

• What may be needed to detect known failures? 
For example, sensors mounted in key locations, 
algorithms, integrated models, etc. 

• How may one approach detection of unknown 
failures? For example, use consistency checks. 

When a product is provided, it should include all ISHM 
related information 

B. Implementation of core elements 

ISHM is rarely implemented at a high functional 
capability level (FCL). In fact, a method or approach to 
measure FCL has not yet been established. However, it is 
reasonable to assume that ISHM capability must be 
implemented incrementally, as it is about embedding DIaK 
and the ability to manage DIaK. Implementing ISHM 
capability on-board a system may be paralleled to a person 
acquiring a new skill, which takes time and is built upon 
initial basic skills. Hence, the question we wish to answer in 
this section is how to begin implementation of ISHM 
capability. 

Regardless of whether one is embedding ISHM capability 
on a legacy system or a yet-to-be-built system, the following 
elements must be implemented: 

• Architecture/Taxonomy/Ontology (ATO). 
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• Standards and protocols. 

Beyond this, one must select a suitable software 
environment able to support the List of Capabilities in 
Section II. Once these core elements are in place, it is a 
matter of embedding information and knowledge, including 
processes and approaches, in order to have the ISHM perform 
the List of Functions in the Introduction Section. 

C. Systematic augmentation of capability 

Initial capability of an ISHM system might just be a 
support capability that makes easily available to the user, 
information that is normally provided in data sheets, manuals, 
and product descriptions. The IEEE 1451.x Transducer 
Electronic Data Sheet (TEDS) standards are especially 
suitable for this implementation, as far as transducers are 
concerned [2-5]. The standards need to be expanded to 
include Component electronic Data Sheet (CEDS), Actuator 
Electronic Data Sheet (AEDS), and perhaps others as well 
[ 2 ]. 

Next, one can begin to implement process models (rules, 
algorithms, etc.) and begin to employ reasoning to infer 
health related information in an integrated manner. For 
example, one may be running a running standard deviation 
algorithm to determine noise level in all signals. One should 
be able to easily compare noise levels in elements that share a 
physical location to infer, perhaps, that wires in one sensor 
are loose. 

The FCL of the ISHM never reaches 100%, because one 
can never embed enough DIaK to ensure that all possible 
anomalies will be detected and identified. Hence, FCL is 
incrementally augmented as new methods and technologies 
become available. 

IV. TESTBEDS AND ON-BOARD ISHM 

Testbeds are always needed to develop, mature, and 
validate products, especially products that require a high 
degree of reliability. Testbeds for ISHM, however, are unlike 
others. ISHM testbeds are about determining all failure 
modes of a system, whereas other testbeds are about making 
sure a system does not fail under expected operating 
conditions. One difficult problem is that it is impossible to 
reproduce all possible anomalies, or even worse, many 
anomalies are not known or understood. This is a key 
validation problem, and is just beginning to be addressed [8]. 
ISHM capability is built using many proven technologies, 
and a few core, yet un-proven technologies that address the 
integration, intelligence, and on-board aspects. Testbeds 
required to elevate the Technical Readiness Level (TRL) of 
technologies addressing these aspects are unique and 
different from typical testbeds. 


A. Testbed requirements 

Different types of testbeds perform functions that lead to 
incremental and methodic implementation of ISHM 
capability both, on ground operations systems, and on space 
platforms and vehicles. At research facilities, testbeds must 
be adequate to prove the technologies and capabilities under 
simulated scenarios, and if possible use data and information 
from real systems, especially from ground testbeds. At 
operations centers, testbeds are the complex systems within 
the facilities themselves (ISS, RETS, Launch Facilities). 
These are complex systems in operation, well characterized 
and documented (specifications, descriptions, procedures, 
models that describe the processes from multiple perspectives 
and at multiple degrees of granularity), with historical DIaK 
describing anomalies and normal operation, and algorithms to 
detect the anomalies. Use of ground test and operations 
facilities and the ISS as testbeds provides two main benefits: 
(1) the facilities themselves are updated/enhanced with 
embedded ISHM capability, and establish credibility with 
operators, leading to a natural migration to flight systems, 
and (2) the facilities are used to develop, test, and validate 
ISHM technologies. 

A very important mode of use of operational testbeds is 
the Non-Interference Mode (or Shadow Mode), whereby the 
testbed is being used for other projects, and the ISHM system 
has access to all DIaK from the testbed, and can execute all 
the functions in the List of Functions of Section I at gradually 
increasing FCLs. 

In the case of NASA, primary ground testbeds for ISHM 
include the rocket engine test stands (RETS) at the NASA 
Stennis Space Center in Mississippi, the International Space 
Station (most operations are done from ground at Mission 
Control), and the launch facilities with permanent systems 
that support launch operations at NASA Kennedy Space 
Center. There are many laboratory testbeds, but the Advanced 
Diagnostics and Prognostics Testbed (ADAPT) at Ames 
Research Center has been recently implemented to support 
ISHM R&D activities. 

B. Development and validation in testbeds 

Development and validation of low TRL technologies can 
be done in laboratory testbeds. However, development and 
validation of an operational ISHM requires higher complexity 
testbeds such as those represented by operational facilities 
(e.g. RETS). Not only do developers have to be satisfied with 
the ISHM implementation, but also users. In fact, users and 
developers should work together in order to implement a 
credible capability. It is also the most efficient approach to 
move the technology from operation testbeds such as RETS 
or the ISS to flight systems, as these technologies are 
carefully verified by developers and users. The issue of 
validation of ISHM capability is, in fact, a very difficult one. 
For more information on validation and verification of ISHM 
systems, please see [8]. 
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C. Development of on-board ISHM capability 

On-board ISHM capability should be developed by 
migrating proven capability and technologies validated in 
operational ground testbeds. 

D. Sustained improvement of ISHM capability 

As ISHM capability is evolutionary, that is, it is meant to 
achieve higher and higher FCL during the design phase, and 
throughout the operational/maintenance cycles of the system. 
This incremental augmentation of FCL needs to be supported 
by continuous research, development, test, and validation 
activities supported by the testbeds. Users and experts must 
continue the process of augmenting capability that is 
developed through the activities cited in Subsections A thru 
C. 

V. CONCLUSION 

Development of embedded ISHM capability on systems 
can be done now, using existing technology, and maturing the 
following core elements that address integration and 
embedding of intelligence: (1) definition of architecture, 
taxonomy, and ontology; (2) definition of standards and 
protocols for management of DIaK across all elements of a 
system; and (3) use of a software environment suitable for 
“intelligent applications,” with tools for management of DIaK 
for networked elements, and not just data (typical scientific 
tools), or just qualitative information (typical artificial 
intelligence tools), or centralized approaches (as opposed to 
distributed). Furthermore, appropriate testbeds must be used 
at each stage of development, where operational testbeds 
become essential in maturing and validating the technology 
prior to porting to flight systems. Operational testbeds are 
also existing resources and do not require much investment to 
be used for this purpose. Furthermore, a systems approach 
must be followed to design, operate, maintain, and retire 
systems with ISHM capability. The potential benefits from 
this approach include increased reliability, reduced costs, and 
sustainable and long-life systems. 
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